LTE (Long-Term Evolution, sometimes called 4G LTE) is a standard for wireless communication of high-speed data for mobile phones and data terminals. It is based on the Global System for Mobile communications (GSM)/Enhanced Data rates for GSM Evolution (EDGE) and Universal Mobile Telecommunications System (UMTS)/High Speed Packet Access (HSPA) network technologies, increasing the capacity and speed using a different radio interface together with core network improvements.
The Radio Resource Control (RRC) protocol is the Radio Resource Control protocol used in UMTS and LTE on the Air interface. It handles the control plane signaling of Layer 3 between the User Equipment (UE) and the Radio Access Network (Universal Terrestrial Radio Access Network (UTRAN) or Evolved Universal Terrestrial Radio Access Network (E-UTRAN)) as well as for the radio interface between a Relay Node and the E-UTRAN. This protocol is specified by the 3rd Generation Partnership Project (3GPP) in TS 25.331 for UMTS and in TS 36.331 for LTE. RRC messages are transported via the PDCP-Protocol.
The major functions of the RRC protocol include connection establishment and release functions, broadcast of system information, radio bearer establishment, reconfiguration and release, RRC connection mobility procedures, paging notification and release and outer loop power control. By means of the signaling functions the RRC configures the user and control planes according to the network status and allows for Radio Resource Management strategies to be implemented.
FIG. 1 shows Radio Resource Control (RRC) Protocol States for Long Term Evolution (LTE). As described in 3GPP TS 36.33, in LTE, a terminal can be in two different states, RRC_CONNECTED and RRC_IDLE.
In RRC_CONNECTED, there is an RRC context. The cell to which the User Equipment (UE) belongs is known and an identity of the UE, the Cell Radio-Network Temporary Identifier (C-RNTI), used for signaling purposes between the UE and the network, has been configured. RRC_CONNECTED is intended for data transfer to/from the UE.
FIG. 2 provides an overview of the RRC states in Evolved Universal Terrestrial Radio Access (E-UTRA) with the illustration of the mobility support between E-UTRAN, UTRAN and GSM EDGE Radio Access Network (GERAN).
Mobility State of UE (36.304): Besides Normal-mobility state, a High-mobility and a Medium-mobility state are applicable if the parameters (TCRmax, NCR_H, NCR_M and TCRmaxHyst) are sent in the system information broadcast of the serving cell. These states can be considered substates as related to mobility in RRC_IDLE state.
NCR_M: This specifies the maximum number of cell reselections to enter Medium-mobility state.
NCR_H: This specifies the maximum number of cell reselections to enter High-mobility state.
TCRmax: This specifies the duration for evaluating allowed amount of cell reselection(s).
TCRmaxHyst: This specifies the additional time period before the UE can enter Normal-mobility state.
State detection criteria:                Medium-mobility state criteria: If number of cell reselections during time period TCRmax exceeds NCR_M and not exceeds NCR_H        High-mobility state criteria: If number of cell reselections during time period TCRmax exceeds NCR_H        
The UE shall not count consecutive reselections between same two cells into mobility state detection criteria if same cell is reselected just after one other reselection.
State transitions:
The UE shall:                if the criteria for High-mobility state is detected: enter High-mobility state.        else if the criteria for Medium-mobility state is detected: enter Medium-mobility state.        else if criteria for either Medium- or High-mobility state is not detected during time period TCRmaxHyst: enter Normal-mobility state.        
Details of the Non-access Stratum NAS Protocol for LTE are described in 3GPP TS 23.401 and 3GPP TS 24.301. A summary is provided below.
The non-access stratum (NAS) forms the highest stratum of the control plane between UE and MME at the radio interface over the reference point Uu. Main functions of the protocols that are part of the NAS are:                the support of mobility of the user equipment (UE); and        the support of session management procedures to establish and maintain IP connectivity between the UE and a packet data network gateway (PDN GW).        
As such, the NAS consists of two separate protocols that are carried on direct signaling transport between the UE and for e.g. the Mobile Management Entity (MME) in the Core Network (CN). The content of the NAS layer protocols is not visible to the Radio Access Network (RAN) nodes (e.g. eNodeB), and the RAN nodes are not involved in these transactions by any other means, besides transporting the messages, and providing some additional transport layer indications along with the messages in some cases. The NAS layer protocols include EPS Mobility Management (EMM), and EPS Session Management (ESM).
EPS Mobility Management (EMM): The EMM protocol is responsible for handling the UE mobility within the system. It includes functions for attaching to and detaching from the network, and performing location updating in between. This is called Tracking Area Updating (TAU), and it happens in idle mode. Note that the handovers in connected mode are handled by the lower layer protocols, but the EMM layer does include functions for re-activating the UE from idle mode. The UE initiated case is called Service Request, while Paging represents the network initiated case. Authentication and protecting the UE identity, i.e. allocating the temporary identity Globally Unique Temporary UE Identity GUTI to the UE are also part of the EMM layer, as well as the control of NAS layer security functions, encryption and integrity protection. Example of EMM procedures include attach procedure (for registration), detach procedure, service request procedure, tracking area update procedure, connection suspend, connection resume procedure and UE reachability procedure. NAS security is an additional function of the NAS providing services to the NAS protocols, e.g. integrity protection and ciphering of NAS signaling messages.
EPS Session Management (ESM): This protocol may be used to handle the bearer management between the UE and MME, and it is used in addition for E-UTRAN bearer management procedures. Note that the intention is not to use the ESM procedures if the bearer contexts are already available in the network and E-UTRAN procedures can be run immediately. This would be the case, for example, when the UE has already signaled with an operator affiliated Application Function in the network, and the relevant information has been made available through the PCRF.
The overall Evolved Packet System Control Plane Protocol stack is depicted in FIG. 3.
In RRC_IDLE, there is no RRC context in the Radio Access Network (RAN) and the UE does not belong to a specific cell. No data transfer may take place in RRC_IDLE. A UE in RRC_IDLE monitors a Paging channel to detect incoming calls and changes to the system information. Discontinuous Reception (DRX) is used in to conserve UE power. When moving to RRC_CONNECTED, the RRC context needs to be established in both the RAN and the UE.
The System Information (SI) is the information broadcast by the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) that needs to be acquired by the User Equipment (UE) to be able to access and operate within the network. The following excerpt from section 5.2.1.1 of 3GPP TS 36.331 provides a general description of the System Information that is broadcast by the E-UTRAN:
“System information is divided into the MasterInformationBlock (MIB) and a number of SystemInformationBlocks (SIBs). The MIB includes a limited number of most essential and most frequently transmitted parameters that are needed to acquire other information from the cell, and is transmitted on Broadcast Channel (BCH). SIBs other than SystemInformationBlockType1 are carried in SystemInformation (SI) messages and mapping of SIBs to SI messages is flexibly configurable by schedulingInfoList included in SystemInformationBlockType1, with restrictions that: each SIB is contained only in a single SI message, and at most once in that message; only SIBs having the same scheduling requirement (periodicity) can be mapped to the same SI message; SystemInformationBlockType2 is always mapped to the SI message that corresponds to the first entry in the list of SI messages in schedulingInfoList. There may be multiple SI messages transmitted with the same periodicity. SystemInformationBlockType1 and all SI messages are transmitted on DL-SCH
Detailed descriptions of the MIB and SIB1 are available in section 6.2.2 of 3GPP TS 36.331. Detailed descriptions of the remaining SIBs (SIB2-SIB20) are available in section 6.3.1 of 3GPP TS 36.331.
The MIB and SIB1 use a fixed schedule with a periodicity of 40 ms and 80 ms respectively. The remaining SIBs use a flexible schedule that can be network dependent. The following excerpt from section 5.2.1.2 of 3GPP TS 36.331 describes the scheduling in more detail:
“The MIB uses a fixed schedule with a periodicity of 40 ms and repetitions made within 40 ms. The first transmission of the MIB is scheduled in subframe #0 of radio frames for which the SFN mod 4=0, and repetitions are scheduled in subframe #0 of all other radio frames.
The SystemInformationBlockType1 uses a fixed schedule with a periodicity of 80 ms and repetitions made within 80 ms. The first transmission of SystemInformationBlockType 1 is scheduled in subframe #5 of radio frames for which the SFN mod 8=0, and repetitions are scheduled in subframe #5 of all other radio frames for which SFN mod 2=0.
The SI messages are transmitted within periodically occurring time domain windows (referred to as SI-windows) using dynamic scheduling. Each SI message is associated with a SI-window and the SI-windows of different SI messages do not overlap. That is, within one SI-window only the corresponding SI is transmitted. The length of the SI-window is common for all SI messages, and is configurable. Within the SI-window, the corresponding SI message can be transmitted a number of times in any subframe other than MBSFN subframes, uplink subframes in Time Division Duplex (TDD), and subframe #5 of radio frames for which SFN mod 2=0. The UE acquires the detailed time-domain scheduling (and other information, e.g. frequency-domain scheduling, used transport format) from decoding SI-RNTI on Physical Downlink Control Channel (PDCCH) (see TS 36.321).
A single SI-RNTI is used to address SystemInformationBlockType1 as well as all SI messages.
SystemInformationBlockType1 configures the SI-window length and the transmission periodicity for the SI messages.”
System information validity and notification of changes is described in detail in section 5.2.1.3 of 3GPP TS 36.331. Change of system information, other than for Earthquake and Tsunami Warning System (ETWS), Commercial Mobile Alert System (CMAS) and Extended Access Barring (EAB) parameters, occurs at specific radio frames. For example, the concept of a modification period is used. The modification period boundaries are defined by System Frame Number (SFN) values for which SFN mod m=0, where m is the number of radio frames comprising the modification period.
When the network changes system information, for instance at least some of the system information, it first notifies the UEs about this change. For example, this may be done throughout a modification period. In the next modification period, the network transmits the updated system information. These general principles are illustrated in FIG. 4. Referring to FIG. 4, blocks 402 are original SI transmitted during modification period (n), blocks 404 are updated SI transmitted during modification period (n+1), and blocks 406 are SI that are not updated at the modification period boundary.
The Paging message is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about a system information change. If the UE receives a Paging message including the systemInfoModification, it knows that the system information will change at the next modification period boundary.
SystemInformationBlockType1 includes a value tag, systemInfoValueTag, that indicates if a change has occurred in the SI messages. UEs may use systemInfoValueTag, e.g. upon return from out of coverage, to verify if the previously stored SI messages are still valid. Additionally, the UE considers stored system information to be invalid after 3 hours from the moment it was successfully confirmed as valid, unless specified otherwise.
FIG. 5 is a diagram that illustrates a system information acquisition procedure from 3GPP TS 36.331. Referring to FIG. 5, a UE 502 communicates with U-TRAN 504 for system information acquisition. The UE 502 applies the system information acquisition procedure described in section 5.2.2 of 3GPP TS 36.331 to acquire the Access Stratum (AS) and Non-access Stratum (NAS) related system information that is broadcasted by the E-UTRAN 504. The procedure applies to UEs in RRC_IDLE and UEs in RRC_CONNECTED. The UE 502 applies the system information acquisition procedure for the following, for example:                Upon selecting (e.g. upon power on) and upon re-selecting a cell        After handover completion        After entering E-UTRA from another Radio Access Technology (RAT)        Upon return from out of coverage        Upon receiving a notification that the System Information has changed        Upon receiving an indication about the presence of an ETWS notification, a CMAS notification and/or a notification that EAB parameters have changed        Upon receiving a request from CDMA2000 upper layers        Upon exceeding the maximum validity duration        
When the eDRX cycle is longer than the system information modification period, the UE 502 verifies that stored system information remains valid before establishing an RRC connection. Paging message can be used for system information change notification, when including systemInfoModification-eDRX, for a UE 502 configured with eDRX cycle longer than the system information modification period.
A bandwidth reduced low complexity (BL) UE can operate in any LTE system bandwidth but with a limited channel bandwidth of 6 PRBs (corresponding to the maximum channel bandwidth available in a 1.4 MHz LTE system) in downlink and uplink.
A BL UE may access a cell only if the MIB of the cell indicates that access of BL UEs is supported. If not, the UE considers the cell as barred.
A BL UE receives a separate occurrence of system information blocks (sent using different time/frequency resources). A BL UE has a transport block size (TBS) limited to 1000 bit for broadcast and unicast. The BL UE determines the scheduling information for SIB1 specific for BL UEs based on information in MIB. Scheduling information for other SIBs is given in SIB1 specific for BL UEs. The BCCH modification period for BL UEs is a multiple of the BCCH modification period provided in SIB2. The SIB transmission occasions within an SI-window are provided in the SIB1 specific for BL UEs. A BL UE can acquire SI messages across SI windows. The maximum number of SI messages that can be acquired across SI windows is 4. A BL UE is not required to detect SIB change when in RRC_CONNECTED.
Turning now to system information handling for UEs in enhanced coverage, UE in enhanced coverage is a UE that requires the use of enhanced coverage functionality to access the cell. A UE may access a cell using enhanced coverage functionality only if the MIB of the cell indicates that access of UEs in enhanced coverage is supported. System information procedures for UEs in enhanced coverage are identical to the system information procedures for bandwidth reduced low complexity UEs. A UE capable of enhanced coverage acquires, if needed, and uses legacy system information when in normal coverage if it is not a BL UE. A UE capable of enhanced coverage acquires, if needed, and uses system information specific for UEs in enhanced coverage. A UE in enhanced coverage is not required to detect SIB change when in RRC_CONNECTED.
The cell selection and reselection procedures performed by a UE in RRC_IDLE are described in section 5.2 of 3GPP TS 36.304]. FIG. 6 is high level flow chart illustrating the cell selection and reselection processing performed by the UE 502 in RRC_IDLE. The procedure can be entered whenever a new PLMN is selected or if a suitable cell can't be found upon leaving RRC_CONNECTED. Referring to FIG. 6, after a cell is selected, in step 602, the UE 502 camps on the cell in step 604 and performs the tasks defined in sections 5.2.6 or 5.2.9 of 3GPP TS 36.304, depending on whether the UE 502 has camped on a suitable cell or an acceptable cell, respectively. When camped on a cell, the UE 502 regularly searches for a better cell according to the cell reselection criteria, as defined in section 5.2.3.2 of 3GPP TS 36.304.
The Cell Reselection Evaluation process, in step 606, is performed according to internal UE 502 triggers or when information on the BCCH used for the cell reselection evaluation procedure has been modified. Upon re-selecting a cell, a UE 502 in RRC_IDLE is required to apply the System Information Acquisition procedure as defined in section 5.2.3 of 3GPP TS 36.331 to obtain the following system information for the new serving cell, for example:                MasterInformationBlock        SystemInformationBlockType1        SystemInformationBlockType2 through SystemInformationBlockType8 (depending on support of the concerned RATs)        SystemInformationBlockType17 (depending on support of RAN-assisted WLAN interworking)        
System Information for the new serving cell that is acquired during the Cell Reselection Evaluation Process (e.g., MIB, SIB1, SIB2) might not have to be re-acquired following the cell reselection, for example if the information has not changed.
IMT for 2020 and beyond [Recommendation ITU-R M.2083: IMT Vision—“Framework and overall objectives of the future development of IMT for 2020 and beyond” (September 2015)] is envisaged to expand and support diverse families of usage scenarios and applications that will continue beyond the current IMT. Furthermore, a broad variety of capabilities would be tightly coupled with these intended different usage scenarios and applications for IMT for 2020 and beyond. The families of usage scenarios for IMT for 2020 and beyond include, for example:                eMBB (enhanced Mobile Broadband)        Macro and small cells        1 ms Latency (air interface)        Spectrum allocated at WRC-15 may lead up to 8 Gbps of additional throughput        Support for high mobility        URLLC (Ultra-Reliable and Low Latency Communications)        Low to medium data rates (50 kbps-10 Mbps)        <1 ms air interface latency        99.999% reliability and availability        Low connection establishment latency        0-500 km/h mobility        mMTC (massive Machine Type Communications)        Low data rate (1-100 kbps)        High density of devices (up to 200,000/km2)        Latency: seconds to hours        Low power: up to 15 years battery autonomy        Asynchronous access        Network Operation        Network Operation addresses the subjects such as Network Slicing, Routing, Migration and Interworking, Energy Saving, etc.        
The following deployment scenarios are being considered primarily for eMBB. Deployment scenarios for mMTC and URLLC are still under study, however, the eMBB deployment scenarios below are likely to also be applicable to mMTC and URLLC.
The following 5 deployment scenarios are being considered for eMBB: Indoor Hotspot, Dense Urban, Rural, Urban Macro and High Speed.
Indoor Hotspot: this deployment scenario focuses on small coverage per site/TRP (Transmission and Reception Point) and high user throughput or user density in buildings. The key characteristics of this deployment scenario are high capacity, high user density and consistent user experience indoor.
Dense Urban: the dense urban microcellular deployment scenario focuses on macro TRPs with or without micro TRPs and high user densities and traffic loads in city centers and dense urban areas. The key characteristics of this deployment scenario are high traffic loads, outdoor and outdoor-to-indoor coverage.
Rural: this deployment scenario focuses on larger and continuous coverage. The key characteristics of this scenario are continuous wide area coverage supporting high speed vehicles.
Urban Macro: the urban macro deployment scenario focuses on large cells and continuous coverage. The key characteristics of this scenario are continuous and ubiquitous coverage in urban areas.
High Speed: Beyond 2020, there will be a growing demand for mobile services in vehicles, trains and even aircrafts. While some services are the natural evolution of the existing ones (navigation, entertainment, etc.), some others represent completely new scenarios such as broadband communication services on commercial aircrafts (e.g., by a hub on board). The degree of mobility required will depend upon the specific use case, with speeds greater than 500 km/h.
Additionally, the urban coverage for massive connection deployment scenario has been identified specifically for mMTC use case.
Urban coverage for massive connection: The urban coverage for massive connection scenario focuses on large cells and continuous coverage to provide mMTC. The key characteristics of this scenario are continuous and ubiquitous coverage in urban areas, with very high connection density of mMTC devices. This deployment scenario is for the evaluation of the KPI of connection density.
Furthermore, the following deployment scenarios have been identified for the UR/LL use case.
Highway Scenario: The highway deployment scenario focuses on scenario of vehicles placed in highways with high speeds. The main KPIs evaluated under this scenario would be reliability/availability under high speeds/mobility (and thus frequent handover operations).
Urban Grid for Connected Car: The urban macro deployment scenario focuses on scenario of highly densely deployed vehicles placed in urban area. It could cover a scenario where freeways lead through an urban grid. The main KPI evaluated under this scenario are reliability/availability/latency in high network load and high UE density scenarios.
Examples of mMTC applications include Light Weight Devices, video Surveillance with variable data size and warehouse applications.